-
Notifications
You must be signed in to change notification settings - Fork 110
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
update management policies with GMP changes #510
Conversation
✅ Deploy Preview for crossplane ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
dbab508
to
f060ff3
Compare
Vale seems to complain for Also btw, I would like to add a guide for using |
Re: Vale - I have some suggested edits for you but before I make them I want to make sure I understand the feature- These changes came in 1.13? For Are there any restrictions on what can be combined as a policy (even if it seem to make sense)? Is this chunk from crossplane-runtime the supported set of combinations?
I'm not following what this is telling me to do/why to do it. |
Thanks. Added them.
Yeah, these changes are a part of the Granular managmenent policy / ingore changes that came in 1.13, but are actually implemented on a provider level, so they will be released with the next provider release ( for now just the Upbound official ones).
Late initialization has been around for a while, its not a part of this feature. But its related because this feature now allows us to skip Late Initialization by setting up a granular management policy which does not include it. A big part of the ignore changes feature requests came because Crossplane was late-initializing some fields that users wanted to be left alone. I saw that Late Initialize section was removed from the docs, probably unintentionally, so I found an old version from the repo and returned it back. Maybe it could do some rework, to avoid confusion on what it actually does.
yeah we support by default a certain set of policies, which is subject to change if somebody has a good use case. The providers have an option to set their own set of polices to support if they prefer so.
Reworded, basically it means that in most cases you should use a mangement policy which does not have |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for all the work Lovro! There are a lot of suggestions but it's mainly big chunks of moving things around.
Let me know if you have any questions or objections to my suggestions.
The `"Delete"` action replaces the [deletionPolicy]({{<ref "./managed-resources#deletionpolicy" >}}) | ||
field in the managed resource. For now the `deletionPolicy` is still supported, | ||
but only if it's set to a non default value, which is `Orphan`. If it's set to | ||
`Orphan`, and the `managementPolicies` is set to `["*"]`, which is default, | ||
then the external resource will be orphaned when the managed resource is | ||
deleted. In other cases, non default `managementPolicies` take precedence over | ||
the `deletionPolicy` field. Keep in mind that this behavior is only applicable | ||
if the management policy alpha feature is enabled. To sum it up in a table: | ||
|
||
{{< table >}} | ||
| managementPolicies | deletionPolicy | result | | ||
|-----------------------------|------------------|---------| | ||
| "*" (default) | Delete (default) | Delete | | ||
| "*" (default) | Orphan | Orphan | | ||
| contains "Delete" | Delete (default) | Delete | | ||
| contains "Delete" | Orphan | Delete | | ||
| doesn't contain "Delete" | Delete (default) | Orphan | | ||
| doesn't contain "Delete" | Orphan | Orphan | | ||
{{< /table >}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I recommend deleting this section and moving text into the deletionPolicy section, under options, earlier in the doc.
http://docs.crossplane.io/v1.13/concepts/managed-resources/#options
#### Interaction with management policies
If a resource configures a Crossplane
[management policy](#managementpolicies) the
default management policy supports `deletionPolicy: Orphan`.
{{< hint "warning" >}}
Any management policy using `Delete`, except for the default policy, ignores
`deletionPolicy: Orphan`.
Crossplane deletes any resources with a `Delete` management policy, even with
`deletionPolicy: Orphan` configured.
{{< /hint >}}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed it and added to the suggested place. But I left the table there, as there is another rule to the ones above:
Crossplane orphans any resources without a `Delete` managment policy, except for the default one, even with `deletionPolicy: Delete` configured.
Seems like much simpler to see it in a table then in words.
{{<hint "important" >}} | ||
The managed resource `initProvider` option is an alpha feature related to | ||
[managementPolicies]({{<ref "./managed-resources#managementpolicies" >}}). | ||
|
||
Enable the `initProvider` in a provider with `--enable-management-policies` | ||
in a | ||
[ControllerConfig]({{<ref "./providers#controller-configuration" >}}). | ||
{{< /hint >}} | ||
|
||
The `spec.initProvider` is a subset of the `spec.forProvider` fields that | ||
Crossplane merges with `forProvider` to create the external resource, but | ||
ignores when updating it. This allows users to create a resource with all the | ||
required fields which may then be controlled externally. For example, a user may | ||
want to create a `NodeGroup` with the required `desiredSize` field, but then | ||
let an autoscaler control the field. If the `desiredSize` field is included | ||
in the`forProvider` field, Crossplane will attempt to update the field, which | ||
will conflict with the autoscaler. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggested restructure to improve wording and flow and add {{<hover>}}
support.
{{<hint "important" >}} | |
The managed resource `initProvider` option is an alpha feature related to | |
[managementPolicies]({{<ref "./managed-resources#managementpolicies" >}}). | |
Enable the `initProvider` in a provider with `--enable-management-policies` | |
in a | |
[ControllerConfig]({{<ref "./providers#controller-configuration" >}}). | |
{{< /hint >}} | |
The `spec.initProvider` is a subset of the `spec.forProvider` fields that | |
Crossplane merges with `forProvider` to create the external resource, but | |
ignores when updating it. This allows users to create a resource with all the | |
required fields which may then be controlled externally. For example, a user may | |
want to create a `NodeGroup` with the required `desiredSize` field, but then | |
let an autoscaler control the field. If the `desiredSize` field is included | |
in the`forProvider` field, Crossplane will attempt to update the field, which | |
will conflict with the autoscaler. | |
{{<hint "important" >}} | |
The managed resource `initProvider` option is an alpha feature related to | |
[managementPolicies]({{<ref "./managed-resources#managementpolicies" >}}). | |
Enable the `initProvider` in a provider with `--enable-management-policies` | |
in a | |
[ControllerConfig]({{<ref "./providers#controller-configuration" >}}). | |
{{< /hint >}} | |
The `spec.initProvider` is a subset of the `spec.forProvider` fields that | |
Crossplane merges with `forProvider` to create the external resource, but | |
ignores when updating it. This allows users to create a resource with all the | |
required fields which may then be controlled externally. For example, a user may | |
want to create a `NodeGroup` with the required `desiredSize` field, but then | |
let an autoscaler control the field. If the `desiredSize` field is included | |
in the`forProvider` field, Crossplane will attempt to update the field, which | |
will conflict with the autoscaler. |
The
{{<hover label="initProvider" line="7">}}initProvider{{</hover>}} defines
settings Crossplane applies only when creating a new managed resource.
Crossplane ignores settings defined in the
{{<hover label="initProvider" line="7">}}initProvider{{</hover>}}
field that change after creation.
{{<hint "note" >}}
Settings in `forProvider` are always enforced by Crossplane. Crossplane reverts
any changes to a `forProvider` field.
Settings in `initProvider` aren't enforced by Crossplane. Crossplane ignores any
changes to a `initProvider` field.
{{</hint >}}
Using `initProvider` is useful for setting initial values that a Provider may
automatically change, like an auto scaling group.
For example, creating a
{{<hover label="initProvider" line="2">}}NodeGroup{{</hover>}}
with an initial
{{<hover label="initProvider" line="9">}}desiredSize{{</hover>}}.
Crossplane doesn't change the
{{<hover label="initProvider" line="9">}}desiredSize{{</hover>}}
setting back when the Provider auto scales the Node Group.
{{< hint "tip" >}}
Crossplane recommends configuring
{{<hover label="initProvider" line="6">}}managementPolicies{{</hover>}} without
`LateInitialize` to avoid conflicts with `initProvider` settings.
{{< /hint >}}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Applied, just added a slight change to
Settings in `forProvider` are always enforced by Crossplane. Crossplane reverts
any changes to a `forProvider` field.
Settings in `initProvider` aren't enforced by Crossplane. Crossplane ignores any
changes to a `initProvider` field.
to
Settings in `forProvider` are always enforced by Crossplane. Crossplane reverts
any changes to a `forProvider` field in the external resource.
Settings in `initProvider` aren't enforced by Crossplane. Crossplane ignores any
changes to a `initProvider` field in the external resource.
To make a clear distinction in making changes in managed its external resource
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
changes to fix vale and improve table display. Otherwise LGTM. Approving, assuming there's no problems with the suggestions.
Signed-off-by: lsviben <[email protected]>
Signed-off-by: lsviben <[email protected]>
Signed-off-by: lsviben <[email protected]>
Signed-off-by: lsviben <[email protected]>
Signed-off-by: lsviben <[email protected]>
Signed-off-by: lsviben <[email protected]>
Signed-off-by: lsviben <[email protected]>
Signed-off-by: lsviben <[email protected]>
Signed-off-by: Hasan Turken <[email protected]>
Signed-off-by: Hasan Turken <[email protected]>
Signed-off-by: Hasan Turken <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#### Late Initialization | ||
|
||
For some of the optional fields, users rely on the default that the cloud | ||
provider chooses for them. Since Crossplane treats the managed resource as the | ||
source of the truth, values of those fields need to exist in `spec` of the | ||
managed resource. In each reconciliation, Crossplane will fill the value of | ||
a field that's left empty by the user but is assigned a value by the provider. | ||
For example, there could be two fields like `region` and `availabilityZone` and | ||
you might want to give only `region` and leave the availability zone to be | ||
chosen by the cloud provider. In that case, if the provider assigns an | ||
availability zone, Crossplane gets that value and fills `availabilityZone`. Note | ||
that if the field is already filled, the controller won't override its value. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it needs it's own subsection at least. In my experience, the late initialization behavior is something unexpected for the users, so it would be good to have it mentioned in more detail.
Agreed to have a dedicated section, so that we can refer to it. It would be more important with management policies where users can turn on/off this behavior.
#### Late Initialization | ||
|
||
For some of the optional fields, users rely on the default that the cloud | ||
provider chooses for them. Since Crossplane treats the managed resource as the | ||
source of the truth, values of those fields need to exist in `spec` of the | ||
managed resource. In each reconciliation, Crossplane will fill the value of | ||
a field that's left empty by the user but is assigned a value by the provider. | ||
For example, there could be two fields like `region` and `availabilityZone` and | ||
you might want to give only `region` and leave the availability zone to be | ||
chosen by the cloud provider. In that case, if the provider assigns an | ||
availability zone, Crossplane gets that value and fills `availabilityZone`. Note | ||
that if the field is already filled, the controller won't override its value. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#### Late Initialization | ||
|
||
For some of the optional fields, users rely on the default that the cloud | ||
provider chooses for them. Since Crossplane treats the managed resource as the | ||
source of the truth, values of those fields need to exist in `spec` of the | ||
managed resource. In each reconciliation, Crossplane will fill the value of | ||
a field that's left empty by the user but is assigned a value by the provider. | ||
For example, there could be two fields like `region` and `availabilityZone` and | ||
you might want to give only `region` and leave the availability zone to be | ||
chosen by the cloud provider. In that case, if the provider assigns an | ||
availability zone, Crossplane gets that value and fills `availabilityZone`. Note | ||
that if the field is already filled, the controller won't override its value. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pushed a commit to fix that.
Late update for the management policies alpha feature.
Replaces the old
managementPolicy
tomanagementPolicies
, updates the Importing guide and adds a section forspec.initProvider
.Fixes: #497